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@ Datenverarbeitungsgestiitztes elektronisches Steuerungssystem, insbesondere fur ein Kraftfahrzeug 

@ Die Erfindung bezieht sich auf ein Steuerungssystem 
mit einem Anwendungsfunktionen ausfuhrenden Steuer- 
gerateverbund mit mehreren, verteilt angeordneten Steu- 
ergeraten und einem diese verbindenden Datenubertra- 
gungsnetzwerk. 

Erfindungsgemafc sind die Anwendungsfunktionen in 
Form einer Client/Server-Architektur in dem Steuergera- 
teverbund implementiert. Dies ermoglicht die Durchfuh- 
rung von Anwendungsfunktionen in Echtzeit mittels eines 
flexiblen, standardisierten und offenen Systems, mit dem 
Anderungen und/oder Erganzungen von Anwendungs- 
funktionen mit relativ geringem Aufwand realisierbar 
sind. 

Verwendung z. B. als Steuerungssystem in einem Kraft- 
fahrzeug. 
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Beschreibung 

Die Erfindung bezieht sich auf ein datenverarbeitungsge- 
sttitztes elektronisches Steuerungs system mit einem An- 
wendungsfunktionen ausfiihrenden Steuergerateverbund 5 
mit mehreren, verteilt angeordneten Steuergeraten und ei- 
nem dicsc verbindenden Datcnubcrtragungsnctzwcrk. Dcr 
Begriff Steuerungssystem ist hierbei in seinem weiteren, 
auch Regelungssysteme umfassenden Sinne zu verstehen. 

Derartige Steuerungssysteme werden beispielweise in 10 
Kraftfahrzeugen eingesetzt, um dort die fahrzeugtypischen 
Steuerungsfunktionen auszufiihren. In herkommlichen Sy- 
stemen werden die Steuergerate jeweils spezifisch fur eine 
oder mehrere Anwendungsfunktionen ausgelegt. Die Imple- 
mentierung einer neuen Fahrzeugfunktion erfordert den Ent- 15 
wurf eines zugehorigen neuen Steuergerates und dessen 
Einbau im Fahrzeug zusammen mit einer neuen Sensor- und 
Aktuatorkonfiguration. Zwar sind die Steuergerate in mo- 
derneren Konfigurationen z. B. iiber einen CAN-Bus ver- 
netzt, jedoch existieren keine expliziten Schnittstellen fur 20 
den Zugriff auf einzelne Funktionsteile, so daB die jeweilige 
Anwendungsfunktion aus Sicht des Steuergerates nur als 
Ganzes in Erscheinung tritt. Zur Realisierung von neuen, 
auf existierende Funktionen aufgebauten, sogenannten re- 
kombinierten Funktionen miissen diese folglich mit hohem 25 
Aufwand von Hand an existierende Funktionen angeschlos- 
sen werden, z. B. durch Definition oder Anderung entspre- 
chender CAN-Botschaften. In ungiinstigen Fallen macht 
dies fur die Hinzufiigung einer einzelnen neuen Funktion 
die Anderung alter anderen Steuergerate notig. Dies fiihrt 30 
zusammen mit dem Trend zu immer mehr elektronisch rea- 
lisierten Funktionen im Kraftfahrzeug und deren zunehmen- 
der Kopplung untereinander zu einer stark anwachsenden 
Komplexitat und zu entsprechenden Schwierigkeiten bei der 
Entwicklung und Beherrschung der gesamten Fahrzeug e- 35 
lektronik sowie zu einem steigenden Bedarf an Rechenlei- 
stung und Speicherumfang. Zudem ergibt sich durch die 
steigende Komplexitat bei gleichzeitig immer mehr Baurei- 
hen und kurzeren Entwicklungszeiten fur dieselben der Be- 
darf, Komponenten vermehrt baureiheniibergreifend wie- 40 
derverwenden zu konnen. 

Von reinen Datenverarbeitungssystemen, z. B. zur Biiro- 
kommunikation und in GroBreehenanlagen, mit verteilten 
Rechnerkapazitaten ist es bekannt, sogenannte Client/Ser- 
ver-Architekturen vorzusehen, um einen jeweiligen Dienst 45 
von einem hierauf ausgelegten Server fur diesen Dienst auf- 
rufende Clients zentralisiert zu erbringen. Bei diesen Syste- 
men ist im allgemeinen keine Echtzeitverarbeitung gegeben. 

Der Erfindung liegt als technisches Problem die Bereit- 
stellung eines insbesondere auch fur Kraftfahrzeuge an- 50 
wendbaren Steuerungssystems der eingangs genannten Art 
zugrunde, das sich zur Durchfiihrung der Anwendungsfunk- 
tionen in Echtzeit und auch mit relativ knappen Rechenka- 
pazitaten eignet und moglichst flexibel, stand ardisiert und 
offen ausgelegt ist, um Anderungen und/oder Erganzungen, 55 
insbesondere hinsichtlich Implernentierung neuer und/oder 
Modifikationen bestehender Anwendungsfunktionen, mit 
vergleichweise geringem Aufwand realisieren zu konnen. 

Die Erfindung lost dieses Problem durch die Bcrcitstcl- 
lung eines Steuerungssystems mit den Merkmalen des An- 60 
spruchs 1. Bei diesem datenverarbeitungsgestutzten elektro- 
nischen Steuerungssystem sind die vom System durchzu- 
fiihrenden Anwendungsfunktionen in Form einer Client/ 
Server- Arc hi tektur in den Steuergerateverbund implemen- 
tiert. Die Client/Server- Architektur wird vorliegend in ei- 65 
nem sogenannten Embedded- System verwendet, d. h. einem 
System, in welchem die elektronische Datenverarbeitungs- 
funktionalitat in ein iibergeordnetes System, wie z. B. eine 



Fahrzeugfunktionen ausfiihrende Fahrzeugelektronik, die- 
ses sttitzend eingebettet ist und dem Anwender nicht direkt 
in Erscheinung tritt. Durch die Ubertragung der aus Daten- 
verarbeitungssystemen bekannten Client/Server-Architek- 
tur auf das vorliegende Steuerungssystem wird ein Modell 
zur Strukturierung verteilter Anwendungen bereitgestellt, 
das besonders gut zur Beschreibung crcignisoricnticrtcr Sy- 
steme geeignet ist, wobei im Unterschied zu konventionel- 
len Systemen die Schnittstellen zwischen Client- und Ser- 
ver-Prozessen prirnar an Diensten und nicht an Daten orien- 
tiert sind. Mit dem vorliegenden System konnen die Anwen- 
dungsfunktionen hardwareunabhangig entwickelt und rela- 
tiv einfach zwecks Erzeugung neuer, hoherwertiger Anwen- 
dungsfunktionen rekornbiniert werden. Im Rahmen der 
Client/Server- Architektur werden die Anwendungsfunktio- 
nen beschrieben, die iiber definierte Anwendungsprotokoll- 
Schnittstellen miteinander kommunizieren, wozu zum Ent- 
wurfszeitpunkt noch keine Aussage iiber die Art der physi- 
kalischen Kommunikation gemacht wird. Damit lassen sich 
durch das erlindungsgemaBe Steuerungssystem Anwen- 
dungsfunktionen in Echtzeit durchfiihren und vergleichs- 
weise einfach in verschiedene Systemauslegungen, z. B. bei 
verschiedenen Fahrzeugbaureihen, implementieren. Die 
elektronische Infrastruktur des Steuerungssystems besitzt 
durch die Verwendung des Client/Server-Architekturmo- 
dells eine flexible, standardisierte und offene Basis und eig- 
net sich insbesondere auch fur Systeme mit vergleichsweise 
geringen Rechenleistungsressourcen und statischer S oft- 
ware- Konfiguration . 

Bei einem nach Anspruch 2 weitergebildeten Steuerungs- 
system beinhaltet die Client/Server- Architektur fiir eine je- 
weilige Anwendungsfunktion eine zwischen einer Client- 
ebene und einer Serverebene liegende Funktionsmonitor- 
ebene, die den globalen Zustand der Anwendungsfunktion 
verwaltet und somit als deren zentrale Schaltstelle oder Ge- 
dachtnis fungiert. In weiterer Ausgestaltung dieser Struktu- 
rierung sind nach Anspruch 3 eine oder mehrere dieser drei 
Ebenen in spezieller Weise weiter strukturiert Die Client- 
ebene kann hierbei aus Requestoren als Quellen von Dienst- 
anforderungen und nachgeschalteten primaren Clients be- 
stehen, wahrend analog dazu die Serverebene aus primaren 
Servern und nachgeschalteten Fulfillern aufgebaut sein 
kann. Ein primarer Client und der zugehorige Requestor 
bzw. ein primarer Server und der zugehorige Fulfiller wer- 
den stets auf demselben Steuergerat angeordnet. Die Moni- 
torebene beinhaltet einen mit den primaren Clients kommu- 
nizierenden Funktionsmonitor, der den globalen Zustand der 
Anwendungsfunktion verwaltet, und von diesem abhangige 
Monitore fiir die Verwaltung von Teilfunktionen. 

Der Funktionsentwurf basiert auf einer Menge von defi- 
nierten Designelenienten wie Methoden und Protokolle, 
Service- Access-Points und Service- Access-Point-Inter- 
faces, Ports und Portinterfaces, Verbindungen, Prozessen, 
Frames und Firmwareprozessen. In Weiterbildung der Erfin- 
dung nach Anspruch 4 sind die Service- Access-Points cha- 
rakteristischerweise so ausgelegt, daB sie Schnittstellen von 
Anwendungsprozessen zur Schicht 7 des ISO/QSI-Refe- 
renzrnodells bilden und je ein Protokoll in Client- und in 
Scrvcrrollc cnthaltcn. In einer Ausgestaltung dcr Erfindung 
nach Anspruch 5 sind die Ports als Ankerpunkte fiir bidirek- 
tionale Client/Server-Kommunikations verbindungen zur 
Implementierungszeit ausgelegt und stellen eine horizontale 
Kommunikations-Schnittstelle auf der Schicht 7 des ISO/ 
OSI-Referenzmodells dar. 

In weiterer Ausgestaltung der Erfindung nach Anspruch 6 
sind die Prozesse als Designelemente, welche die eigentli- 
che Anwendungssoftware beinhalten, in spezieller Weise 
aus einer auBeren Schnitts telle, einer inneren Struktur und 
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einem spezifischen Verhalten auf eingehende Dienstanfor- 
derungen aufgebaut. 

In Weiterbildung der Erfindung nach Anspruch 7 besitzt 
das Steuerungssystem ein echtzeitfahiges Multitasking-Be- 
triebssystem in den Steuergeraten, und die Client/Server- 5 
Prozesse sind so implementiert, daB sie ohne direkten Hard- 
warczugriff nur die Dicnstc des Bctricbssy stems und cincr 
zugehorigen Kommunikationsschicht nutzen, die auf der so- 
genannten Remote-Procedure- Call (RPC)-Technik basiert, 
wie sie der Art nach von Datenverarbeitungssystemen mit 10 
Client/Server- Architektur fiir eine solche Kommunikation 
zwischen Client/Server-Prozessen bekannt ist. 

In weiterer Ausgestaltung der Erfindung ist nach An- 
spruch 8 vorgesehen, daB in einer entsprechenden RPC-Bi- 
bliothek ein vollstandiger Server-Code enthalten ist, der pro 15 
Steuergerat genau einmal eingebunden ist und von alien 
Client- und Server- Prozessen abgearbeitet wird. Dies mini- 
miert den Ressourcenbedarf und maximiert gleichzeitig die 
Wiederverwendungsfahigkeit. 

In weiterer Ausgestaltung der Erfindung erfolgt die Initia- 20 
lisierung des Servers gemaB Anspruch 9 in vier speziellen 
Phasen. 

GemaB einer Weiterbildung der Erfindung nach Anspruch 
10 ist der Remote-Procedure- Call (RPC) als synchroner 
RPC, asynchroner RPC oder Oneway-RPC realisiert. 25 

In Weiterbildung der Erfindung nach Anspruch 11 ist eine 
minimale bzw. ressourcenoptimierte Protokollirnplementie- 
rung vorgesehen, die jeder Methode eine identifizierende 
Dienstnummer zuweist und bei der in den Nutzdaten der 
versendeten Nachrichten sowohl der Nachrichtentyp als 30 
auch die Dienstnummer und die iibergebenden Daten co- 
diert sind. Das so implementierte Protokoll ist z. B. auf ei- 
nem CAN-Bus verwendbar. 

Vorteilhafte Ausfiihrungsformen der Erfindung sind in 
den Zeichnungen dargestellt und werden nachfolgend be- 35 
schrieben. Hierbei zeigen: 

Fig. 1 eine ausschnittweise Blockdiagramm-Darstellung 
eines Steuergerateverbundes eines Kraftfahrzeug-Steue- 
rungssystems, 

Fig, 2 eine Blockdiagramm-Darstellung der Entwurfs- 40 
struktur einer im Steuerungssystem von Fig. 1 implemen- 
tierten Client/Server- Architektur, 

Fig, 3 eine Darstellung des graphischen Erscheinungsbil- 
des der inneren Struktur einer ProzeBklasse fiir die Client/ 
Server-Architektur, 45 

Fig. 4 eine graphische Darstellung der Einbettung eines 
endlichen Automaten in eine ProzeBklasse der Client/Ser- 
ver- Architektur, 

Fig. 5 eine graphische Darstellung des Client/Server-De- 
signs am Beispiel einer Ruckfahrscheinwerfer-Anwen- 50 
dungsfunktion, 

Fig. 6 ein Blockdiagramm der fur die Client/Server- Ar- 
chitektur verwendeten Steuergerate-Software, 

Fig. 7 eine blockdiagrammatische Darstellung der Pro- 
zeBkommunikation der Client/Server- Architektur mittels 55 
Protokollen auf Anwendungsschichtebene, 

Fig. 8 ein Blockdiagramm eines prinzipiellen ORPC-Ab- 
laufs in der Client/Server- Architektur, 

Fig. 9 ein FluBdiagramm des Scrvcr-Arbcitsablaufs in der 
Client/Server- Architektur, 60 

Fig. 10 ein FluBdiagramm des Ablaufs einer Server-In- 
itialisierungsphase, 

Fig. 1 1 ein FluBdiagramm einer synchronen RPC-Imple- 
mentierung, 

Fig. 12 ein FluBdiagramm einer Oneway-RPC-Imple- 65 
mentierung und 

Fig. 13 eine schematische Blockdiagramm-Darstellung 
des implementierten Protokolls der Client/Server- Architek- 
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tur. 

Fig. 1 zeigt ausschnittweise und blockdiagrammatisch 
mehrere, verteilt angeordnete Steuergerate la, lb, lc und 
ein diese verbindendes Datenubertragungsnetzwerk mit ei- 
nem Datenbus 2, z. B. einem CAN-Bus, eines Steuergerate- 
verbunds zur Ausfuhrung von Anwendungsfunktionen in ei- 
nem Kraftfahrzcug. In dem Steuergerate verb und dieses 
Steuerungssys terns sind die Anwendungsfunktionen in 
Form einer Client/Server- Architektur (CSA) implementiert, 
die dafiir sorgt, daB alle Systemschnittstellen beschrieben 
sind und nur iiber selbige mit den Objekten kommuniziert 
wird und Daten ausgetauscht werden. Soweit diese Client/ 
Server-Architektur in ihrer Struktur und ihren Komponenten 
den herkommlichen Client/Server- Architekturen entspricht, 
wird darauf im folgenden nicht naher eingegangen, sondern 
auf die betreffende Literatur verwiesen und die entspre- 
chende Terminologie verwendet. Durch diese Architektur 
wird eine Portability der Software zwischen verschiedenen 
Hardware- Plattforrnen erreicht. Die Nutzung eines von her- 
kommlichen objektorientierten Methoden bekannten Con- 
struction-from-Parts-Ansatzes kann dafiir sorgen, daB sich 
einmal spezifizierte, implementierte und getestete Pro- 
grammteile immer wieder verwenden lassen. Weiter wird 
durch Realisierung der Kommunikation auf Basis eines Re- 
mote-Procedure-Calls (RPC) gewahrleistet, daB einzelne 
Prozesse beliebig im Steuergeratenetzwerk verteilt werden 
konnen, ohne die Funktionsentwiirfe oder die implemen- 
tierte Software manuell anpassen zu miissen. Fig. 1 veran- 
schaulicht beispielhaft, wie auf diese Weise eine Applika- 
tion aus einem Client-ProzeB 3, einem Funktionsmonitor 3b 
und einem Server-ProzeB 4a, 4b auf den Steuergeraten la, 
lb, lc verteilt werden kann. Ein weiterer Server 4a gehort 
nicht zu dieser Client/Server-Kette. Der Funktionsmonitor 
3b fungiert sowohl als Server (gegeniiber Client 3) wie auch 
als Client (gegeniiber Server 4b). 

Fig. 2 zeigt im Blockdiagramm den Systementwurf einer 
jeweiligen Anwendungsfunktion im Rahmen der erfin- 
dungsgemaB verwendeten Client/Server- Architektur. Ge- 
maB diesem Systementwurf ist die jeweilige Anwendungs- 
funktion in eine Clientebene 5, eine Serverebene 6 und eine 
zwischenliegende Funktionsmonitorebene 7 strukturiert. 
Die Clientebene 5 beinhaltet einen oder mehrere primare 
Clients 5a mit vorgeschaltetem Requestor 5b. Die Requesto- 
ren 5b reprasentieren ereignisauslbsende Hardwareeinhei- 
ten, wie Sensoren, und die zugehorige Steuergerate-Firm- 
ware. Sie stellen die Quellen von Dienstanforderungen der 
modellierten Anwendungsfunktion dar. Die primaren 
Clients 5a verwalten die Requestoren, nehmen deren 
Dienstanforderungen entgegen und setzen gegebenenfalls 
weitere Auftrage an die Funktionsmonitorebene 7 ab. Die 
primaren Clients 5a werden stets auf demselben Steuergerat 
wie der zugehorige Requestor 5b angesiedelt und erlauben 
es, die Dienstanforderung auch fiber Kommunikationsme- 
dien weiterzuleiten, wozu der Requestor 5b nicht ausgelegt 
ist. Die Funktionsmonitorebene 7 beinhaltet fiir jede An- 
wendungsfunktion einen Funktionsmonitor 7a, der die 
Dienstanforderungen von primaren Clients 5a und gegebe- 
nenfalls von Funktionsmonitoren iibergeordneter Anwen- 
dungsfunktionen entgegennimmt und bcarbcitct. Er kann 
dazu weitere Dienste von ihm untergeordneten Monitoren 
oder primaren Servern in Anspruch nehmen. Der Funktions- 
monitor 7a verwaltet den globalen Zustand der Anwen- 
dungsfunktion und bildet damit deren zentrale Schaltstelle 
und Gedachtnis. Dem Funktionsmonitor 7a sind innerhalb 
der Funktionsmonitorebene 7 gegebenenfalls ein oder meh- 
rere Monitore 7b nachgeschaltet, die Teilfunktionen verwal- 
ten und sich vom Funktionsmonitor 7a dadurch unterschei- 
den, daB sie nicht direkt mit primaren Clients 5a und Funk- 
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tionsmonitoren 7a anderer Anwendungsfunktionen kommu- 
nizieren. Die Serverebene 6 beinhaltet einen oder mehrere 
primare Server 6a und einen jeweils zugehorigen Fulfiller 
6b. Die Fulfiller 6b reprasentieren ausfuhrende Hardware- 
Einheiten, wie Aktuatoren, und die zugehorige Steuerge- 5 
rate- Firmware. Sie stellen die Senken von Dienstanforde- 
rungen dcr modcllicrtcn Anwcndungsfunktion dar. Die pri- 
maren Server 6a verwalten die Fulfiller 6b und beauftragen 
diese mit der Ausfiihrung von Diensten. Sie sind stets auf 
demselben Steuergerat wie der zugehorige Fulfiller 6b ange- 10 
siedelt und erlauben es, Dienstanforderungen von entfernten 
Monitoren 7b entgegenzunehmen, worauf die Fulfiller 6b 
nicht ausgelegt sind. 

Die Pfeile in Fig. 2 reprasentieren Client/Server-Bezie- 
hungen, wobei der Pfeil vom Client zum jeweiligen Server 15 
verlauft und fiir ein bestimmtes Anwendungsprotokoll steht. 
Normalerweise verhalt sich ein Server dabei synchron zu 
den aufrufenden Clients. Die Richtung der Pfeile deutet auf 
diese Betriebsart hin. In Ausnahmesituationen ist es jedoch 
auch moglich, daB ein Server 6a asynchron Informationen 20 
an einen oder rnehrere seiner Clients 5a sendet. In diesem 
Ausnahmebetrieb findet eine Umkehr der jeweiligen Rollen 
statt, fiir die ein eigenes Protokoll zu vereinbaren ist. 

Der Funktionsentwurf fiir die Client/Server- Architektur 
mit der in Fig. 2 dargestellten Anwendungs-Entwurfsstruk- 25 
tur basiert auf einer Menge von hierfur geeignet definierten 
Designelementen. Die Entwurfsmethodik sieht dabei eine 
spezielle graphische Notation fiir die Designelemente vor, 
wodurch sie von graphischen Entwurfswerkzeugen unter- 
stiitzt werden kann, was die Lesbarkeit von Entwiirfen so- 30 
wie das Erlernen der Methodik verglichen mit rein textuel- 
len Notationen erleichtert. Speziell sind als Designelemente 
den Requestoren 5b eine Sensor- Firmware, den Fulfillern 6b 
eine Aktuator-Firmware, den Client/Server-Beziehungen 
Verbindungen und den primaren Clients 5a, den Funktions- 35 
monitoren 7a, den Monitoren 7b und den primaren Servern 
6a ProzeBklassen zugeordnet. 

Allgemein sind als Designelemente Methoden und Proto- 
kolle, Service- Access-Points (SAP) und Service- Access- 
Point-Interfaces (SAPIF), Ports und Port-Interfaces (Por- 40 
tIF), Verbindungen, Datenelemente, Prozesse, Frames und 
Firmware-Prozesse vorgesehen. Methoden stellen in diesem 
Zusammenhang Funktionalitat dar, die eine ProzeBklasse 
anderen ProzeBklassen als Dienste an den SAPs in Server- 
rolle zur Verfiigung stellt. Andererseits kann dieselbe Pro- 45 
zeBklasse an SAPs in Clientenrolle Dienste anfordern, die 
von anderen ProzeBklassen als Methoden an SAPs in Ser- 
verrolle angeboten werden. Methoden haben wie herkomm- 
liche Funktionsaufrufe eine Typ und Argumente, wobei der 
Typ angibt, welches Datenformat der Ruckgabewert der 50 
Methode hat. Fiir die Anwendung ist es transparent, ob die 
Dienstanforderung als Remote-Procedure-Call mittels Sen- 
den/Empfangen uber ein externes physikalisches Kommuni- 
kations medium, mittels InterprozeBkommunikation oder 
mittels Eventmechanismus vom Client zum Server kommu- 55 
niziert wird. Protokolle dienen der Aggregierung von Me- 
thoden. Zu diesem Zweck beinhalten sie eine Liste von Me- 
thoden, die aus Sicht des Anwendungsentwicklers eine 
funktionalc Einhcit darstcllcn. Des wcitcrcn konnen Proto- 
kolle hierarchisch strukturiert werden, d. h. es kann eine 60 
Hierarchie von Protokollen dergestalt aufgebaut werden, 
daB ausgehend von einem Null-Protokoll, das keine Metho- 
den enthalt, eine Baumstruktur von Protokollen entsteht, in 
der ein neu hinzugefugtes Protokoll alle Methoden des zur 
Wurzel des Baumes hin nachstliegenden Protokolles erbt 65 
und gegebenenfalls weitere hinzufiigt. 

Die SAPs sind die Schnittstellen von Anwendungsprozes- 
sen zur Schicht 7 des ISO/OSI-Referenzmodells und bein- 
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halten je ein Protokoll in Client- und in Serverrolle. Die 
SAPs haben eine Vorzugsrichtung, die entweder der Client- 
oder der Serverrolle entspricht. Da SAPs Endpunkte von 
mehreren Client/Server-Kommunikationsverbindungen sein 
konnen, beinhalten sie eine entsprechende Anzahl an Ports, 
die der Verankerung der einzelnen Kommunikationsverbin- 
dungen dienen. SAPIFs machen SAP-Funktionalitat an Pro- 
zeB- und Frameklassen-Schnittstellen verfiigbar, wobei ein 
SAP innerhalb einer ProzeBklasse Verbindungen zu mehre- 
ren SAPIFs haben kann. Dies bietet unter anderem die Mog- 
lichkeit, den SAPIFs entsprechende Namen zu geben, z. B. 
Riickfahrlicht rechts, Riickf ahrlicht links, und damit den ge- 
zielten AnschluB weiterer Komponenten zu ermoglichen, 
obwohl die Funktionalitat von einem einzigen SAP erfullt 
wird. SAPIFs existieren nur wahrend des hierarchischen Sy- 
stementwurfs. Nach Auflosung der Hierarchie vor der In- 
stanzierung besteht keine Notwendigkeit mehr, diesem De- 
signelement eine Entsprechung in der Implementierung zu 
geben. 

Ports sind Ankerpunkte fiir bidirektionale Client/Server- 
Kommunikationsverbindungen zur Implementierungszeit. 
In dieser Eigenschaft stellen sie eine horizontale Kommu ni- 
kationsschnittstelle auf Schicht 7 des ISO/OSI-Referenzmo- 
dells dar. An den Ports wird der eigentliche Kommunikati- 
onsmechanismus verankert, d. h. das Senden/Empfangen 
uber externe physikalische Kommunikationsmedien, die In- 
terprozeBkommunikation und ein Eventmechanismus fiir 
die effektive Kommunikation mit Finnware-Prozessen. Von 
einem SAP ausgehende Dienstanforderungen konnen folg- 
lich uber unterschiedliche Kommunikationsmechanismen 
weitergeleitet werden, je nachdem, mit welchem Kommuni- 
kationsmechanismus der jeweils gerade angesprochene Port 
hinterlegt ist. Analog zu den SAPIFs machen die PortlFs 
Port- Funktionalitat an Schnittstellen von nachfolgend be- 
schriebenen ProzeB- und Frameklassen verfiigbar. Die Por- 
tlFs gehoren entweder zur Schnittstelle eines gerade entwor- 
fenen Frames oder zur Schnittstelle eines darin enthaltenen 
Frames oder Prozesses. 

Jede ProzeBklasse kann Datenelemente enthalten, welche 
sie im Sinne der Objektorientierung kapselt. Ein Datenele- 
ment hat einen Datentyp und kann durch einen Initialisie- 
rungswert vorbelegt werden. Es kann konstant oder variabel 
sein und ist dementsprechend in einem ROM oder RAM an- 
geordnet. Ferner werden die Datenelemente als private oder 
public klassifiziert. Die Initialisierung von private-Datenele- 
menten hat direkt beim Entwurf der ProzeBklasse zu erfol- 
gen, wahrend diejenige von public-Datenelementen auf ei- 
ner hierarchisch hoheren Designebene geschieht, wenn der 
entsprechende Kontext bekannt ist, in welchem die ProzeB- 
klasse verwendet wird. Die in der ProzeBinstanz gekapselten 
Datenelemente konnen nur von der ProzeBinstanz selbst ge- 
andert werden. 

Ein ProzeB im Rahmen der vorliegenden Client/Server- 
Architektur hat Schnittstellen, uber die er mit anderen Pro- 
zessen oder Frames verbunden werden kann. Er bietet Dien- 
ste an SAPIFs in Serverrolle an und nutzt Dienste von ande- 
ren Prozessoren an SAPIFs in Clientrolle. Das Verhalten ei- 
ner ProzeBklasse wird mittels endlicher Automaten be- 
schricben. Jcdc ProzeBklasse kann als Summc drcicr Kom- 
ponenten betrachtet werden, und zwar einer auBeren 
Schnittstelle, einer inneren Struktur und des Verhaltens. Fig. 
3 zeigt ein Beispiel des graphischen Erscheinungsbildes der 
inneren Struktur einer ProzeBklasse mit einer zugehorigen 
auBeren Schnittstelle. Das Verhalten einer ProzeBklasse als 
Reaktion auf eine eingehende Dienstanforderung gliedert 
sich in drei Teilaspekte, und zwar in die Anderung des inne- 
ren Zustands z der ProzeBklasse, d. h. eines endlichen Auto- 
maten FSM, der das Verhalten der ProzeBklasse reprasen- 
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tiert, in die Modifikationen an den gekapselten Datenele- 
menten (process data set) und die Ausfiihrung von Aktionen 
und gegebenenfalls Wechsel des Prozesses in Clientrolle, 
um Dienste von anderen Prozessen in Anspruch zu nehmen. 
Fig. 4 zeigt die Einbettung des endlichen Automaten, d. h. 5 
der Finite State Machine (FSM), in die ProzeBklasse. Wie 
aus Fig. 4 crkcnnbar, konnen cingchcndc Dicnstanfordcrun- 
gen sowohl den x- Vektor des endlichen Automaten als auch 
den Process Data Set beeinflussen. Andert sich der x- Vektor, 
wird gemaB der Definition des endlichen Automaten ge- 10 
priift, ob gegebenenfalls ein neuer Zustand erreicht wird und 
entsprechende Aktionen ausgefuhrt werden mussen. Welche 
Aktionen ausgefuhrt werden, ergibt sich aus der Interpreta- 
tion des y-Vektors. Das Ausfiihren der Aktionen kann wei- 
tere Anderungen am Process Data Set und den Wechsel in 15 
die Clientrolle mit Anforderung von Diensten anderer Pro- 
zesse bedeuten. Weiter ist der Fig. 4 die charakteristische 
MaBnahme entnehmbar, die SAPs in Server- und Client- 
Modus auf Anwendungsebene zu implementieren. 

Um einen hierarchischen Softwareentwurf zu ermogli- 20 
chen, sind Frames als weitere Designelemente vorgesehen, 
die in ihrer internen Struktur weitere Frames, Prozesse und 
notwendige Verbindungen kapseln konnen. Ein Frame hat 
wie ein ProzeB Schnittstellen, iiber die er mit anderen Pro- 
zessen oder Frames verbunden werden kann. Er bietet Dien- 25 
ste an SAPIFs in Serverrolle an und nutzt Dienste von ande- 
ren Prozessen an SAPIFs in Clientrolle. Prinzipiell konnen 
Frames zusatzlich mit einer Verhaltensbeschreibung verse- 
hen sein, was schlieBlich ein Zusammenf alien mit Prozessen 
bedeuten kann, so daB nur noch eines dieser beiden Desi- 30 
gnelemente auf Designebene benotigt wird. In diesem Fall 
mussen fur die Implementierung einer Anwendung fur alle 
ProzeBklassen auf hierarchisch unterster Designebene expli- 
zite Verhaltensbeschreibungen existieren, wahrend dies fur 
ProzeBklassen auf hierarchisch hoheren Ebenen optional ist, 35 
wobei dann deren Verhaltensbeschreibung mit derjenigen 
der in ihr enthaltenen ProzeBklassen niedrigerer Ebene zu- 
sammenpassen muB. 

Als weiteres Designelement sind Firmware-Prozesse vor- 
gesehen, mit denen Firmware charakteristischerweise als 40 
Prozesse beschrieben wird und die das Bindeglied zwischen 
einer jeweiligen Hardwarekomponente und genau einem zu- 
geordneten primaren Client oder Server bilden. Sie kommu- 
nizieren mit letzteren iiber Anwendungsprotokolle, wie sie 
auch zur Kommunikation zwischen den Prozessen verwen- 45 
det werden und besitzen demzufolge ebenfalls mindestens 
ein SAPIF. Im Unterschied zu Prozessen werden jedoch we- 
der innere Struktur, noch Verhalten von Firmware-Prozes- 
sen beschrieben, es konnen jedoch Datenelemente verwen- 
det werden. 50 

Fig. 5 zeigt am Beispiel der typischen fahrzeugspezifi- 
schen Anwendungsfunktion "Ruckfahrscheinwerfer" bei- 
spielhaft die prinzipielle Vorgehensweise beim Funktions- 
entwurf gemaB dem vorliegenden Client/Server-Modell. 
Die graphische Darstellung von Fig. 5 zeigt hierzu ein auBe- 55 
res Frame 8, das zwei innere Frames 9, 10 und einen durch 
die Graphik seiner auBeren Schnittstelle 11 dargestellten 
ProzeB beinhaltet. Im ersten Schritt erfolgt die Identifikation 
der bctciligtcn Scnsorik und Aktuatorik und darnit die Fcst- 
legung der primaren Clients und Server. Im gezeigten Bei- 60 
spiel wird die Funktion durch einen Schalter an der Schalt- 
kulisse eines Automatgetriebes aktiviert. Als Aktuator wird 
am Fahrzeugheck eine Gluhlampe eingeschaltet. Als End- 
punkte dieses Client/Server- Szenarios ergeben sich damit 
ein primarer Client zur Uberwachung des Ruckfahrschalters 65 
und ein primarer Server zur Ansteuerung der digitalen Lam- 
penendstufe fiir den Ruckfahrscheinwerfer. Die eigentliche 
Funktionslogik befindet sich in einem Monitor, der in die- 
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sem Fall lediglich den Schaltzustand mit der Zundklemmen- 
information verknupft, so daB der Ruckfahrscheinwerfer bei 
ausgeschalteter Ziindung nicht eingeschaltet wird. 

Nachdem auf diese Weise die Struktur der Funktion fest- 
liegt, werden im nachsten Schritt die Protokolle zwischen 
den Clients und Servern definiert. Ein Protokoll besteht da- 
bci aus einer Anzahl von Diensten, die der Server dem 
Calient anbietet. Im Beispielfall eines binaren Schalters ist 
zwischen prirnarem Client und Monitor nur die Information 
"Schalter eingeschaltet" oder "Schalter ausgeschaltet" aus- 
zutauschen. Bei der Aktuatorikansteuerung ergeben sich 
ebenfalls nur zwei Dienste, die der primare Server dem 
Funktionsmonitor anbieten muB, namlich "Endstufe ein- 
schalten" und "Endstufe ausschalten". 

Ein Blick in eine wahrend der Entwicklung entstandene 
Parts-Bibliothek kann zeigen, daB bereits ein Protokoll zur 
Ubertragung binarer Information existiert, das im Beispiel- 
fall sowohl fiir die Kommunikation zwischen prirnarem 
Client und Monitor als auch zwischen Monitor und prirna- 
rem Server genutzt werden kann. Die entsprechenden Pro- 
zesse und Protokolle zur Einspeisung der Ziindklemmenin- 
formation in dieses Funktionsszenario sind ebenfalls bereits 
in der Parts-Bibliothek enthalten, wobei in diesem Fall eine 
Kommunikationsverbindung zu demjenigen Client genugt, 
der die aktuelle Ziindklemme an den Funktionsmonitor wei- 
tergibt. 

Nachfolgend wird detaillierter auf die Implementierung 
der Client/Server-Architektur im Fahrzeug eingegangen. 
Eine grundlegende Komponente bildet das verwendete Be- 
triebssystem. Um die Portabilitat der Client/Server-Prozesse 
auf unterschiedliche Hardware-Plattformen sicherzustellen, 
ist auf den Steuergeraten eine Betriebssystemschicht reali- 
siert, welche die Abhangigkeiten der Software zur Hardware 
kapselt und eine abstrakte Programmierschnittstelle (Appli- 
cation Programming Interface; API) bereitstellt. Vorausset- 
zung fur den Einsatz der Client/Server- Architektur in einem 
Steuergerat ist ein echtzeitfahiges Multitasking-Betriebssy- 
stem. Beispielsweise kann das Echtzeit-Betriebssystem 
OSEK mit der Conformance-Class ECC1 gewahlt werden, 
da fur die Kommunikation der Event-Mechanismus notwen- 
dig ist. Die gegenseitige Unterbrechbarkeit einzelner Tasks, 
d. h. preemptives Scheduling, ist nicht zwingend erforder- 
lich. Fig. 6 zeigt die Struktur von Software- Modulen auf ei- 
nem Steuergerat mit der vorliegenden Client/Server-Archi- 
tektur sowie die Koexistenz zu konventionellen Applikatio- 
nen, wobei zusatzlich die Schichten des ISO/OSI-Referenz- 
modells zu Vergleichszwecken dargestellt sind. Aus Fig. 6 
ist ersichtlich, daB die Client/Server-Prozesse nicht direkt 
auf die Hardware zugreifen, sondern die Dienste des Be- 
triebssystems und der ORPC-Kommunikationsschicht und 
damit des OSEK COM nutzen, wobei die Kommunikations- 
beziehungen zwischen Client/Server- Prozessen mit gestri- 
chelten Linien wiedergegeben sind. Die gebogene Linie re- 
prasentiert eine Client/Server- Kommunikation auf dernsel- 
ben Gerat, wahrend die gerade Linie eine solche zwischen 
verschiedenen Geraten symbolisiert. Durch diese Struktur 
laBt sich eine Verschiebbarkeit der Client/Server- An wen- 
dung zwischen verschiedenen Steuergeraten erreichen, die 
alle iiber entsprechende OSEK OS-, OSEK COM- und 
ORPC-OXDR-Implementierungen verfiigen. In Fig. 7 ist 
die vorliegend getroffene MaBnahme veranschaulicht, die 
SAPs und die Ports fiir das Zusammenspiel von Prozessen 
mittels Protokollen auf dem Niveau von Schicht 7 des ISO/ 
OSI-Referenzmodells zu implementieren. 

Wie gesagt, greifen die Client/Server- An wendungen auf 
Dienste einer Kommunikationsschicht zuriick. Dabei setzt 
die ORPC(OSEK-basierter Remote-Procedure-Call)- 
Schicht auf den Timer- und Event-Diensten des Betriebssy- 



DE 197 48 

9 

stems und den Kommunikationsroutinen der OSEK COM- 
Ebene auf. Die OSEK COM-Schicht stellt Kommunikati- 
onsroutinen bereit, iiber die Tasks miteinander Daten aus- 
tauschen konnen. Die Kommunikation zweier Tasks erfolgt 
konfigurationsabhangig innerhalb desselben Adressraums 5 
oder zwischen verschiedenen Adressraumen iiber ein ent- 
sprcchcndcs Transportmcdium, wobci fur die Anwcndung 
die tatsachliche Realisierung der Kommunikation verborgen 
bleibt. Die Kommunikation sebenen ORPC, OSEK COM, 
Geratetreiber und Hardware bilden die Schichten 6 bis 1 des 10 
ISO/OSI-Referenzmodells, wahrend Schicht 7, d. h. die An- 
wendungsschicht, direkt von der CLient/Server-Anwendung 
bzw. den Anwendungsprotokollen iibernommen wird. 

Die ProzeB struktur der Clients und Server beschreibt das 
Systemverhalten innerhalb der Architektur, womit aller- 15 
dings im Unterschied zu konventionellen Client/Server-Sy- 
stemen keine Interaktion mit der AuBenwelt modelliert 
wird. Diese Schnittstelle zur Umwelt wird in der vorliegen- 
den CSA durch zusatzliche Softwarebausteine, die soge- 
nannte Firmware, gebildet. Diese Firmware trennt die hard- 20 
wareabhangigen Teile der Funktion von der logischen Funk- 
tion des Client/Server-Systems. In ihr werden die Ein- und 
Ausgabeoperationen des Steuergerates behandelt. Norma- 
lerweise sind dies die Ansteuerung von I/O-Pins des Prozes- 
sors mit definiertem Timing. Die Firmware wird hard- 25 
warenah speziell fiir das Steuergerat z. B. in Assembler oder 
C implementiert. Zur Client/Server-Umgebung stellt die 
Firmware eine Schnittstelle iiber Anwendungsprotokolle 
ahnlich denen von Client/Server-Prozessen bereit. Diejeni- 
gen Client- bzw. Server-Prozesse, die Auftrage aus der 30 
Firmware entgegennehmen oder diese beauftragen, werden 
als die primaren Clients bzw. Server bezeichnet, so daB 
diese primaren Prozesse direkt auf dem Steuergerat laufen, 
an dem auch die entsprechende Hardware angeschlossen ist. 
Uber diese Zwischenschicht ist auch eine Kommunikation 35 
zu anderen als den Client/Server-Prozessen denkbar, indem 
fiir die betreffende Applikation eine Schnittstelle zur Client/ 
Server-Umgebung in Form von entsprechender Firmware 
realisiert wird. 

Zwischen zwei Client/Server-Prozessen findet die Kom- 40 
munikation zum Datenaustausch iiber zwei asynchrone, uni- 
direktionale Punkt-zu-Punkt-Kanale statt. Sie basieren auf 
dem Prinzip des aus der Biirokommunikations-Datenverar- 
beitung bekannten Remote-Procedure-Call (RPC), wobei 
dieser Mechanismus fiir den Anwendungsfall von Kraftf ahr- 45 
zeugen auf die dort vorhandenen, begrenzten Ressourcen 
angepaBt und vereinfacht ist. So stehen z. B. keine Name- 
Services oder Security-Functions zur Verfiigung, und es 
wird im allgemeinen auch keine sichere Kommunikation fiir 
den Nachrichtenaustausch vorausgesetzt. Der prinzipielle 50 
Ablauf des verwendeten OSEK-basierten Remote-Proce- 
dure-Call (ORPC) ist in Fig. 8 dargestellt. Bei einer Anfor- 
derung (Request) von einem Client- zu einem Server- ProzeB 
codiert eine Stub-Routine zunachst die Argumente in eine 
netzwerkneutrale, normalisierte Form. Der in der ORPC- 55 
Runtime-Bib liothek bereitgestellte Timed-RPC sorgt fiir die 
Ubertragung des Requests iiber das Netzwerk oder iiber 
Kommunikationsobjekte im selben Adressraum zum Server. 
Dort decodiert die entsprechende Scrvcr-Stub-Routinc die 
Argumente, ruft mit diesen Parametern die Dienstimple- 60 
mentierung auf und nimmt daraufhin die Ergebnisse entge- 
gen. Diese werden wieder in die normalisierte Darstellung 
umgewandelt und zum Client zuriickgesendet. Die Client- 
Stub-Routine sorgt fiir die Decodierung der Ergebnisse und 
gibt sie schlieBlich an den entsprechenden ProzeB zuriick. 65 

Fiir den Fall, daB bei der Ubertragung iiber ein Medium 
zwischen verschiedenen Adressraumen eine Nachricht ver- 
loren geht, ist im ORPC ein Mechanismus implementiert, 
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der Nachrichten wiederholen kann. Dazu ist fiir jede Nach- 
richt definiert, bis zu welchem Zeitpunkt nach dem Vers en- 
den des Requests die Antwort (Reply) erwartet wird. Kann 
diese Zeit nicht eingehalten werden, geht der Client davon 
aus, daB entweder seine Request-Nachricht oder der Reply 
darauf verloren ging. Er sendet deshalb den Request erneut 
aus. Zusatzlich ist cine Maximalanzahl fiir die Wicdcrholun- 
gen definiert, nach denen der Client mit einer entsprechen- 
den Fehlermeldung iiber die Nichterfiillung des Dienstes be- 
nachrichtigt wird. Mit diesem Mechanismus konnen nur 
idempotente Dienste realisiert werden, bei denen eine Wie- 
derholung eines bereits ausgefiihrten Dienstes keinen Ein- 
fluB auf das Gesamtergebnis oder den Systemzustand hat. 

Im Unterschied zu herkommlichen Implementierungen 
von RPC-Mechanismen fiir die Biirokommunikation ist bei 
der vorliegenden CSA weitaus mehr Funktionalitat inner- 
halb der ORPC-Bibliotheksroutinen realisiert und standardi- 
siert. Gangige RPC-Implementierungen stellen der Anwen- 
dung lediglich die benotigten Kommunikationsfunktionen 
in Form einer Bibliothek zur Verfiigung und ermoglichen 
dariiber hinaus nur die Generierung eines prirnitiven Geriists 
fiir die eigentliche Server-Funktionalitat. Wenn dies, wie 
meist der Fall, nicht ausreicht, muB der Anwendungspro- 
grammierer den benotigten Server-Code selbst schreiben. 
Im Gegensatz dazu beinhaltet vorliegend die ORPC -Biblio- 
thek neben den Kommunikationsroutinen auch den vollstan- 
digen Server-Code. Dieser wird von alien Client- und Ser- 
ver-Prozessen abgearbeitet, d. h. er wird pro Steuergerat ge- 
nau einmal eingebunden. Dies erfiillt in vorteilh after Weise 
die Anforderungen nach minimalem Ressourcenbedarf und 
maximaler Wiederverwendungsfahigkeit. Dieser Server- 
Code wird von der Anwendung lediglich mit den jeweiligen 
prozeBspezifischen Daten aufgerufen und arbeitet diese 
nach einem festgelegten Verfahren ab. Das zugehorige Ser- 
ver-Zustandsdiagramm ist in Fig, 9 dargestellt. Nach Aufruf 
durch die Anwendung durchlauft der Server eine Initialisie- 
rungsphase, die sich in vier einzelne Phasen gliedert, wie im 
zugehorigen Initialisierungsdiagramm in Fig, 10 dargestellt. 
Zunachst werden die anwendungsspezifischen ProzeBdaten 
initialisiert, wozu aus dem Server-Code heraus eine anwen- 
dungsspezifische Funktion aufgerufen wird, welche der An- 
wendungsprogrammierer zur Verfiigung stellt. Dann erfolgt 
die Initialisierung der Kommunikationskanale und der zuge- 
horigen Datenobjekte. Der Server-ProzeB ist nun empfangs- 
bereit und kann Anforderungen, d. h. Requests, von seinen 
Clients entgegennehmen. Der ProzeB geht daraufhin fiir eine 
einstellbare Zeit in eine Wartestellung, bis ein Request emp- 
fangen wird oder die eingestellte Zeit abgelaufen ist. Diese 
MaBnahme dient der Lastverteilung beim Anlauf des Sy- 
stems bzw. dazu, unwichtigere Prozesse zu blockieren, bis 
sie tatsachlich benotigt werden. Zuletzt iiberpruft der Server, 
ob er alle notwendigen Initialisierungsinformationen hat. 1st 
dies nicht der Fall, fordert er sie selbsttatig, d. h. ohne Mit- 
wirkung der Anwendung, bei den entsprechenden Clients 
an. Liegt nach einer einstellbaren Anzahl von Versuchen 
noch keine giiltige Initialisierung vor, verzweigt der Server 
in eine Notlauf-Funktion, ansonsten betritt der Server eine 
Schleife, in der er die eingegangenen Anforderungen nach- 
cinandcr ab arbeitet. 

Anstehende Requests werden dem Server-ProzeB iiber ei- 
nen vom Betriebs system bereitgestellten Signalisierungs- 
mechanismus angezeigt. Anhand dieses Signals kann der 
Server zwischen verschiedenen Quellen unterscheiden und 
die entsprechende Bearbeitungsmethode anstoBen. Quelle 
dieser Signale konnen hierbei Nicht-CSA-Funktionen, wie 
Firmware, oder Betriebssystemfunktionen, wie Zeitgeber 
oder Interrupt-Mechanismen, oder andere CSA-Prozesse, 
wie Client-Prozesse, sein. Anhand des empfangenen Signals 
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wird vom Server-Code iiber eine Tabelle am entsprechenden 
SAP eine Stub-Routine aufgerufen. Die Stub-Routinen wer- 
den anhand der Informationen zu den Anwendungsprotokol- 
len automatisch generiert und rufen die vom Anwendungs- 
programmierer zur Verfugung gestellte Dienstimplementie- 5 
rung auf. Bei den Signalen wird zwischen sogenannten App- 
lication Events und den ORPC-Evcnts untcrschicdcn. Die 
Application Events werden zur Anbindung der Firmware 
und fiir Betriebssystemfunktionen genutzt und direkt in ei- 
nen entsprechenden Aufruf umgesetzt. Die ORPC -Events 10 
sind durch den realisierten RPC-Mechanismus vorgegeben 
und dienen zur Anbindung anderer CSA-Prozesse. 

Fiir die Realisierung des RPC kommen drei Varianten in 
Betracht, von denen der gebrauchlichste ein sogenannter 
synchroner RPC ist, der durch die Funktion Timed-RPC der 15 
ORPC-Bibliothek realisiert ist. Fig, 11 zeigt das FluBdia- 
gramm dieser Funktion. Nach der Initialisierung der lokalen 
Daten der Funktion werden in einer Schleife die fiir diese 
Methode konfigurierten Aufrufversuche (Attemps) abgear- 
beitet. Bei jedem Versuch wird hierzu zunachst ein Zeitge- 20 
ber mit dem entsprechenden Timeout- Wert geladen. Im An- 
schluB daran wird der Request versendet und auf den Aus- 
gang dieser Sende-Operation gewartet. War das Senden des 
Requests erfolgreich, betritt die Funktion eine Schleife, in 
der sie auf die Antwort, d. h. den Reply, wartet. Wird die 25 
Antwort nicht innerhalb der vorgegebenen Zeitspanne emp- 
fangen, startet ein erneuter t Jbertragungs versuch, sofern die 
Anzahl moglicher Versuche noch nicht uberschritten ist. 
Lauft der Zeitgeber ab, bevor ein erfolgreicher Ausgang der 
Sendeoperation signalisiert wurde, wird ohne Warten auf 30 
Antwort der nachste Versuch gestartet. Auf Server-Seite 
wird durch den Empfang eines Requests eine entsprechende 
Server-Stub-Routine aufgerufen, welche ihrerseits die ei- 
gentliche Dienstimplementierung aufruft und nach deren 
Abarbeitung eine entsprechende Antwort an den Client-Pro- 35 
zeB zuriicksendet. Abhangig vom Ausgang liefert die Funk- 
tion einen entsprechenden Fehlercode sowie im Erfolgsfall 
das zugehorige Ergebnis an die aufrufende Funktion, in die- 
sem Fall eine Client-Stub-Routine, zuriick. Innerhalb der 
Anwendung muB bei einem RPC zunachst dieser Fehler- 40 
code betrachtet werden, bevor im Erfolgsfall mit dem zu- 
riickgelieferten Ergebnis gearbeitet werden kann. Fiir den 
Fall, daB ein RPC-Vorgang fehlschlagt, ist eine entspre- 
chende Fehlerbehandlung vom Anwendungsprogrammierer 
vorzusehen. 45 

Als weitere Variante kann ein sogenannter asynchroner 
RPC vorgesehen sein. Dieser entspricht einer Modification 
des synchronen RPC dahingehend, daB von der Server-Stub- 
Routine eine Antwort gesendet wird, bevor die eigentliche 
Dienstimplementierung aufgerufen wird. Der Client-ProzeB 50 
kann dadurch asynchron zu dem von ihm beauftragten Ser- 
ver-ProzeB weiterarbeiten. Der Server-ProzeB bzw. die auf- 
gerufene Stub-Routine bestatigt hierbei durch den Reply le- 
diglich den korrekten Empfang des entsprechenden Re- 
quests, nicht jedoch die erfolgte Bearbeitung. Infolgedessen 55 
ist diese Art des RPC nur fiir Methoden zulassig, die kein 
Ergebnis, d. h. einen Riickgabewert vom Typ "void", haben. 
Die Unterscheidung zwischen synchronem und asynchro- 
ncm RPC crfolgt allcin in der Scrvcr-Stub-Routinc, wahrend 
die verwendeten Client-Stub-Routinen in beiden Fallen 60 
identisch sind. Auch wird in beiden Fallen zur Kommunika- 
tion die Funktion Timed-RPC aufgerufen. 

Als dritte Variante kann der sogenannte Oneway-RPC 
vorgesehen sein, bei welchem im Gegensatz zu den beiden 
vorigen Mechanismen keine Antwort vom Server an den 65 
Client generiert wird. Dieser Mechanismus ist ebenfalls nur 
fiir Funktionen zulassig, die kein Ergebnis liefern. Im Unter- 
schied zu Timed-RPC realisiert die verwendete Koimnuni- 
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kationsfunktion Oneway-RPC keinen Timeout-Retransmit- 
Mechanismus und wartet nicht auf eine Antwort des Ser- 
vers. Das zu dieser RPC- Variante gehorige FluBdiagramm 
ist in Fig, 12 dargestellt. 

Neben dem Aufruf der entsprechenden Kommunikations- 
funktion bzw. Dienstimplementierung sind die Client- und 
Scrvcr-Stub-Routincn auch fur das sogenannte Marshalling, 
d. h. die Konvertierung eines einfachen Datentyps aus einer 
prozessorspezifischen Darstellung in das zur Kommunika- 
tion verwendete normalisierte Format, und Unmarshalling, 
d. h. der Datenkonvertierung vom normalisierten Format in 
die prozessorabhangige Darstellung, der zugehorigen Para- 
meter und Riickgabewerte verantwortlich. Dabei werden 
Byte- und Bit-Ordering und die Lange der Darstellung be- 
riicksichtigt. Die Client- und Server-Stub-Routinen werden 
anhand der Signatur einer Methode, d. h. unter Beriicksich- 
tigung von Anzahl, Reihenfolge und Typ der Parameter so- 
wie des Riickgabewertes, automatisch generiert. Die Stub- 
Routinen enthalten die entsprechende Aufruf- Sequenz von 
Konvertierung sroutinen fiir einfache Datentypen. Wahrend 
bei den herkommlichen Realisierungen der Anwendungs- 
programmierer selbst Funktionen fiir das Marshalling bzw. 
Unmarshalling bereitstellen und an die Stub-Routine iiber- 
geben muB, wird diese Funktionalitat hierdurch beim vorlie- 
genden System vollstandig innerhalb der Stubs gekapselt 
und bleibt der Anwendung verborgen. Dadurch ist der in der 
vorliegenden CSA realisierte RPC] beziiglich der Schnitt- 
stelle fiir den Anwendungsprogrammierer transparent, d. h. 
durch die gewahlte Vorgehensweise ist die Schnittstelle der 
Anwendung zu den Stub-Routinen so gestaltet, daB diese 
exakt derjenigen bei einem lokalen Funktions aufruf ent- 
spricht. Fur jede Signatur existiert genau ein Paar von Stub- 
Routinen, wobei Methoden mit gleicher Signatur dieselben 
Stub-Routinen verwenden. Dies ist von der methoden spezi- 
fischen Generierung von Stub-Routinen herkommlicher 
Realisierungen zu unterscheiden. Die vorliegende CSA 
macht im Unterschied zu herkommlichen Architekturen von 
der Moglichkeit einer (Wieder-)Verwendung von Stub-Rou- 
tinen durch mehrere Methoden Gebrauch. 

Eine Randbedingung fiir die normalisierte Darstellung in 
einem Netzwerk ist, daB auf den eingesetzten Microcontrol- 
lern der Aufwand fur die Umsetzung moglichst gering ist. 
Anstelle herkommlicher Realisierungen einer External- 
Data-Representation wurde daher fiir das vorliegende Sy- 
stem eine eigenstandige normalisierte Darstellung in Form 
einer OXDR (OSEK-basierte externe Datenrepresentation) 
definiert. Konvertierungsroutinen fiir einfache Datentypen 
werden in einer Bibliothek zur Verfugung gestellt. OXDR 
zeichnet sich durch eine Trennung von Marshalling- und 
Unmarshalling-Routinen aus, was selektives Einbinden der 
benotigten Module und somit minimalen ROM-Bedarf er- 
moglicht. AuBerdem konnen fiir die Datenkonvertierung 
Quell- und Zieldatenbereich identisch sein, was den RAM- 
Bedarf der Konvertierungsroutinen minimiert. 

Fiir die Protokollimplementierung erhalt jede Methode ei- 
nes Anwendungsprotokolls eine eindeutige, als Dienstnum- 
mer bezeichnete Nummer. Mit dieser identifiziert sowohl 
der Client den gewiinschten Dienst als auch der Server die 
dazugchorende Dienstimplementierung. In den Nachrichtcn 
sind in den Nutzdaten sowohl der Nachrichtentyp, d. h. Re- 
quest, Reply oder Error, als auch die Dienstnummer und die 
iibergebenen Daten kodiert. Fig, 13 zeigt eine Darstellung 
des so realisierten Protokolls. Dabei bedeuten Bit 7 ein Er- 
ror-Flag, Bit 6 Reply-Flag und die Bits 5 bis 0 die Service- 
ID zwischen 0 bis 63. Die Anfangsbits "00 ..." bedeuten ei- 
nen Request fiir den Dienst mit der anschlieBenden Num- 
mer, die Anfangsbits "01 ..." einen Reply auf den Dienst- 
aufruf mit der anschlieBenden Nummer und die Anfangsbits 
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"11. . ." einen Fehler bei der Verarbeitung des Dienstes mit 
der anschlieBenden Nummer. Mit Application-Data sind die 
beim Aufruf der Methode ubergebenen Daten bzw. die Ant- 
wort darauf bezeichnet. Der Client sendet also eine Nach- 
richt mit einer Dienstnummer an seinen Server, der anhand 5 
der geloschten Bits 6 und 7 und der Dienstnummer priift, ob 
es sich um cincn Request handclt und ob cr dicscn Dicnst cr- 
bringen kann. Nach der erfolgreichen Verarbeitung des 
Dienstes sendet der Server die Ergebnisse unter derselben 
Dienstnummer mit dem gesetzten Bit 6 an den Client zu- 10 
ruck. Dieser erkennt an der Dienstnummer, dem gesetzten 
Bit 6 und dem geloschten Bit 7, daft es sich um ein giiltiges 
Ergebnis zum aufgerufenen Dienst handelt. Falls der Server 
einen geforderten Dienst nicht erbringen kann, beantwortet 
er den Request mit einer Fehlernachricht, indem er die Bit 6 15 
und 7 setzt und in den Anwendungsdaten den entsprechen- 
den Fehler kodiert. 

Im Ergebnis steht somit fiir das Steuerungssystem ein ob- 
jektorientierter Ansatz zur Verfiigung, bei der alle in der 
CSA verwendeten Prozesse eine oder mehrere detinierte 20 
Schnittstellen in Form von SAPs bzw. SAPIFs haben, iiber 
die mit Ihnen mittels Anwendungsprotokollen kommuni- 
ziert wird. Die Prozesse konnen lokale Daten besitzen, die 
nur iiber die Anwendungsprotokolle modifiziert werden 
konnen, und sie besitzen einen inneren Zustand, da das Ver- 25 
halten eines solchen Prozesses iiber einen einfachen Auto- 
maten (FSM) festgelegt ist. Damit folgt der Entwurf mit der 
Client/Server-Methode den wesentlichen Paradigmen des 
objektorientierten Designs. Das Design der Anwendung er- 
folgt auf Klassenebene durch Aufbau von Kommunikations- 30 
beziehungen zwischen den ProzeBklassen. Zur Generie- 
rungszeit werden aus diesen kommunizierenden ProzeB- 
klassen die ProzeBinstanzen erzeugt und mit entsprechenden 
Daten vorbelegt, wobei auch Polymorphismus durch Uber- 
schreiben der Dienstimplementierungen an dieser S telle 35 
moglich ist. Als hierarchische Strukturierungsmittel finden 
Frames Verwendung, die andere Frames oder ProzeBklas- 
sen, Firmware und Kommunikationsverbindungen enthalten 
konnen, sogenannte Construction of Parts. Aus diesen 
Frames kann dann nach der Bottomup-Designmethode, d. h. 40 
durch Construction from Parts, die Anwendung zusammen- 
gebaut werden. Ein einmal angelegtes, implementiertes und 
getestetes Frame laBt sich in beliebig vielen Anwendungen 
wiederverwenden, so daB eine erhebliche Effizienz- und Ef- 
fektivitatssteigerung gegeniiber dem konventionellen Ent- 45 
wurf ermoglicht wird. Durch die vorliegend realisierte CSA 
ist eine hohe Flexibilitat auch im Bereich der Kraftfahrzeu- 
gelektronik gegeben, die eine baureiheniibergreifende Ver- 
wendung der Anwendungsfunktionen oder zumindest von 
Teilen derselben erlaubt. Wird beispielsweise bei einer 50 
neuen Baureihe eine Anwendungsfunktion nur hinsichtlich 
ihrer Funktionslogik, nicht aber ihrer zugehorigen Sensorik 
oder Aktuatorik verandert, reicht eine Modifizierung des 
entsprechenden Funktionsmonitors aus. Durch die vorlie- 
gende Strukturierung von Funktionen wird folglich auch die 55 
Wartungsfahigkeit verbessert. 

Der EntwicklungsprozeB wird formal durch ein Design- 
und Implementierungswerkzeug unterstiitzt, mit dem der 
gesamtc DcsingprozcB und Tcilc des Implcmcnticrungspro- 
zesses unterstiitzt werden. Damit konnen in der Design- 60 
phase die ProzeBklassen mit ihren Schnittstellen und Daten 
spezifiziert werden. Zusammen mit den entwickelten An- 
wendungsprotokollen lassen sie sich zu Frames kombinie- 
ren, die ihrerseits in anderen Frames genutzt werden kon- 
nen. Am SchluB des Design-Prozesses fiir eine neue Funk- 65 
tion wird der Kontext festgelegt, in welchem die Frames an- 
gewendet werden, z. B. zur Festlegung der Frequenz und 
des TasLverhaltnisses im Fall der Blinkfunktion eines Fahr- 
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zeugblinkgebers. Aus den mit Hilfe des Entwicklungswerk- 
zeugs entworfenen Funktionen wird eine Parts-Bibliothek 
aufgebaut. 

Wie die vorstehende Beschreibung eines Anwendungs- 
falls fiir ein Kraftfahrzeug zeigt, bietet das erfindungsge- 
maBe Steuerungssystem mit der implementierten Client/ 
Server- Arch itcktur erhebliche Vortcilc. Der Entwicklungs- 
aufwand wird durch systematische Wiederverwendung und 
Anderungsfreundlichkeit sowie weitgehende Automatisie- 
rung vereinfacht, wozu eine klare Trennung zwischen logi- 
schem Entwurf einer Fahrzeugf unktion und deren physikali- 
scher Einbettung in die Steuergeratestruktur realisiert ist. 
AuBer Funktionsentwurfen sind auch entsprechende Simu- 
lationsmodelle und implementierte Software-Module in 
gleicher Weise flexibel einsetzbar, was den Aufwand nicht 
nur in der Entwurfsphase, sondern auch in der Implementie- 
rungs- und in der Integrationsphase verringert. Durch die er- 
findungsgemaBe Systemauslegung ergibt sich ein groBer 
Freiheitsgrad beziiglich der Plazierung einzelner Funktio- 
nen auf den Steuergeraten im vernetzen Steuergeratever- 
bund. 

Wenngleich die Erfindung im Detail anhand eines Kraft- 
fahrzeug-Steuerungssystems erlautert wurde, versteht es 
sich, daB sie auch auf andere Arten von datenverarbeitungs- 
gestiitzten elektronischen Steuerungssystemen mit einem 
Steuergerateverbund aus verteilt angeordneten Steuergera- 
ten anwendbar ist. 

Patentanspriiche 

1. Daten verarbeitungsgestiitztes elektronisches Steue- 
rungssystem, insbesondere fiir ein Kraftfahrzeug, mit 

- einem Anwendungsfunktionen ausfiihrenden 
Steuergerateverbund mit mehreren, verteilt ange- 
ordneten Steuergeraten (la, lb, lc) und einem 
diese verbindenden Dateniibertragungsnetzwerk 
(2), dadurch gekennzeichnet, daB 

- die Anwendungsfunktionen in Form einer 
Client/Server- Architektur in dem Steuergerate- 
verbund implementiert sind. 

2. Steuerungssy stem nach Anspruch 1, weiter dadurch 
gekennzeichnet, daB die Client/Server- Architektur fiir 
eine jeweilige Anwendungsfunktion eine Client-Ebene 
(5), eine Server-Ebene (6) und eine zwischenliegenden 
Funktionsmonitorebene (7) beinhaltet, welche Dienst- 
anforderungen von der Client-Ebene und/oder von 
iibergeordneten Anwendungsfunktionen empfangt und 
unter Benutzung von Diensten der Server-Ebene und/ 
oder von untergeordneten Anwendungsfunktionen be- 
arbeitet. 

3. Steuerungssystem nach Anspruch 2, weiter dadurch 
gekennzeichnet, daB 

- die Client-Ebene (5) wenigstens einen primaren 
Client (5a) und einen zugehorigen Requestor (5b) 
enthalt, wobei der Requestor ereignisauslosende 
Hardware-Einheiten und eine zugehorige Steuer- 
gerate-Firmware reprasentiert und der primare 
Client den Requestor verwaltet, Diensteanforde- 
rungen von ihm entgegennimmt und Auftragc an 
die Funktionsmonitorebene (7) absetzt, und/oder 

- die Funktionsmonitorebene pro Anwendungs- 
funktion einen Funktionsmonitor (7a), der Dienst- 
anforderungen der Client-Ebene (5) entgegen- 
nimmt und bearbeitet, sowie diesem untergeord- 
nete Monitore (7b) zur Verwaltung von Teilfunk- 
tionen enthalt und/oder 

- die Server-Ebene (6) wenigstens einen prima- 
ren Server (6a) und einen zugehorigen Fulhller 
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(6b) beinhaltet, wobei die Fulfiller ausfuhrende 
Hardware-Einheiten und zugehorige Steuerge- 
rate-Firmware reprasentieren und der primare 
Server den Fulfiller verwaltet und mit der Ausfuh- 
rung von Diensten beauftragt sowie Dienstanfor- 5 
derungen von der Funktionsmonitorebene (7) ent- 
gcgcnnimmt. 

4. Steuerungssystem nach einem der Anspriiche 1 bis 

3, weiter dadurch gekennzeichnet, daB als eine Gruppe 
von Designelementen fiir den Funktionsentwurf der 10 
Client/Server- Architektur Service- Access-Points 
(SAPs) vorgesehen sind, die AnwendungsprozeB- 
Schnittstellen auf dem Niveau von Schicht 7 des ISO/ 
OSI-Referenzmodells bilden und je ein Protokoll in 
Client- und Serverrolle beinhalten. 15 

5. Steuerungssystem nach einem der Anspriiche 1 bis 

4, weiter dadurch gekennzeichnet, daB als eine Gruppe 
von Designelementen fiir den Funktionsentwurf der 
Client/Server-Architektur Ports als horizontale Kom- 
munikationsschnittstellen auf Schicht 7 des ISO/OSI- 20 
Referenzmodells als Ankerpunkte fur die bidirektio- 
nale Client/Server-Kommimikationsverbindung zur 
Implementierungszeit vorgesehen sind. 

6. Steuerungssystem nach einem der Anspriiche 1 bis 

5, weiter dadurch gekennzeichnet, daB als eine Gruppe 25 
von Designelementen fiir den Funktionsentwurf der 
Client/Server- Architektur Prozesse in Form von Pro- 
zeBklassen vorgesehen sind, die eine auBere Schnitt- 
stelle, eine innere Struktur und ein Verhalten umfassen, 
welches Anderungen des internen Zustands (z) der Pro- 30 
zeBklasse, Modifikationen an gekapselten Datenele- 
menten und die Ausfiihrung von Aktionen beinhaltet. 

7. Steuerungssystem nach einem der Anspriiche 1 bis 

6, weiter dadurch gekennzeichnet, daB in den Steuerge- 
raten eine Betriebssystemschicht mit einem echtzeitfa- 35 
higen Multitasking-Betriebs system implementiert ist 
und als Kommunikationsschicht eine solche vom Re- 
mote- Procedure-Call-Typ (RPC) verwendet ist, wobei 
die Ciient/Server-Prozesse auf die Dienste des Be- 
triebssj'stems und der Kommunikationsschicht ohne 40 
direkten Hard ware- Zu griff zuriickgreifen. 

8. Steuerungssystem nach Anspruch 7, weiter dadurch 
gekennzeichnet, daB in einer RPC-Bibliothek ein voll- 
standiger Server-Code abgelegt ist, der pro Steuergerat 
genau einmal eingebunden ist und von alien Client- 45 
und Server-Prozessen abgearbeitet wird. 

9. Steuerungssystem nach Anspruch 7 oder 8, weiter 
dadurch gekennzeichnet, daB der RPC- Vorgang fiir die 
Kommunikationsschicht als synchroner, asynchroner 
oder Oneway-RPC-Vorgang realisiert ist. 50 

10. Steuerungssystem nach einem der Anspriiche 7 bis 
9, weiter dadurch gekennzeichnet, daB das Nachrich- 
tenprotokoll Informationen iiber den Nachrichtentyp, 
eine Dienstnurnmer einer jeweiligen Methode eines 
Anwendungsprotokolls und die zu iibergebenden Da- 55 
ten enthalt. 
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